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Cop" protection for SSA with removable memory modules 

Within a few years, Solid State Audio (SSA) players are expected to become the new 
standard for portable audio playback devices. This is mainly due to many advantages 
on weight, size, power use, and last but not least, shock resistance with respect to 
cuiT«.nt Solutions using disc or tape. Currently available SSA players combine 32-64 
MB of flash memory and audio compression techniques such as MPEG 1 layer III 
or AAC to achieve up to one hour of .(near) CD quality music playing tune. 
Due to the digital nature of these devices, however, the music industry demands 
proper copyright protection features. 



One of the tools for copy protection of digital content is encryption. While encryption 
by ivself doea not prevent illegal copying, it does reader such copies useless, as the 
original content can be retrieved only by decrypting it using the proper key. As a 
result, the play back of the content is limited to those devices that have access to that 
key It is a task of the copy protection system to manage the keys in such a way that 
illegal copying is not possible, while at the same time not inconveniencing legal and 
inteaded use of the content. 

In tie following, it is assumed that a SSA player employs detachable memory 
modules which can be accessed by other means as well (e.g. PC based readers). 
Basically two approaches exist for copy protection. The first is to bind the audio to a 
soe-ific player by providing each individual player with a unique, secret, number that 
is used as the key for encryption of the audio. Therefore, the audio stored on memory 
mo-Hiles by one player will play on that player only. Of course, this is very annoying 
if one has multiple SSA players. It is required that one is able to play music stored on 
a it emory module, regardless of the SSA device used to download it onto the module. 
Wr at should be prevented is that a user can not make copy the audio content to 
another module and be able to play from both. 

One solution is to embed a unique identification code in the memory module, which 
can be read by the application, but which can not be changed. This identification code 
can then be used to generate an encryption key, which is specific for the module. 

Ar other solution is to make use of natural defects in the memory (e.g. the Mostly 
Good Memory (MOM) approach of Hitachi to fabricate cheap but high storage 
capacity flash memories). The locations of these defects probably will be unique for 
ea:h module, and as such can act as a 'fingerprint' of that device. Again, a unique key 
caa be generated, which is specific for the module. 

BWow a third solution is outlined, which does not require that each module is 
personalised using a unique identification code. At some point in time, this may be 
advantageous because of privacy consider ations. 

Most of the memory modules currently being proposed for solid state multimedia 
starage applications consist of a large flash memory and an on-board controller. The 
controller may or may not be integrated, and multiple separate memory chips may be 
employed on the module. Examples of multimedia memory modules are: Memory 
Sack (Sony), SmartMedia (SSFDC Forum), Miniature Card (MC Forum), Compact 
Flash (PCMCIA Forum), Multimedia Card (Sandisk, Siemens). In addition, these 
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devices can be thought of as block devices, similar to hard disk drives, in that access 
oc, £ by addressiniscctors (typically 512 bytes) on the module Indeed, some of the 
modules listed above employ the ATA interface standard, which is usedto connect 
hard disks and other peripherals to a PC This enables easy duplication (bit by bit) of 
the content of such memory modules using a PC. Other modules use a proprietary 
iataface and command set, but still are block based, i.e. individual sectors on the 
mcdule can be address and modified. 

To effective* use a storage device, it is necessary to implement a file system by 
means of which the user date is organised and accessed. By treating the memory 
m"c dule as a block device, the creation and management of a file system is left to ^the 
application. In a PC environment, where the operating system already has built-in fite 
w tern support, this is a logical choice: by supporting the AT A standard this support 
cL be reused for the memory module without any modification. However^ in stand- 
alone devices, such as a SSA player, the application is burdened with file system 
*rib T^the memory module employs the block device approach. Therefore, stand- 
alcne (portable) applications which require storage of multimedia wnterii, may be 
bu! h more efficiency if the controller on the memory module takes care of the file 
system details. 

Without going in too much detail, an Application Progxainniing Interface (API) is 
or r^sed forttie memory module, which hides the details of the file system 
ZwnZ. and at theLne time provides features which can be employed for copy 
protection. The memory module is schematically represented in figure 1. 
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Figure 1. Schematic diagram of the memory module 
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The API should contain the following functionality as a minimum: 

1. Format memory 
Input, none 

Output: volume number (optional) 

Remarks: the volume number can be either a unique, hard- wired identification tag 
of the memory module, or a different random number which is generated each 
time this command is executed. It is not possible to change this number, other than 
by executing this command again (thereby destroying all data on the device). (The 
random number generator can be seeded by e.g. the fingerprint of a MGM, or 
thermal or electrical fluctuations in the device.) Note that the copy protection 
system described below, does not require a volume number (though it may be 
useful to have one anyway). 

2. Create file 
Input: none 
Output ; file ID 

Remarks: the file ID is a number by means of which the file is referenced in all 
file operations. It can be reused. 

3. Block write 

Input: file ID> data block (e.g. a sector of 51 2 bytes) 
Output: sector number for the next block write 

Remarks: the sector number for the next block write is randomly chosen (by the 
controller) from the free block list. The application is free to use or discard this 
data at will. Note that the sectors in which the file data are stored can be chosen at 
random from the available sectors because the flash memory is not hampered by a 
seek time common in disk based systems. In addition, it helps to level wear over 
the entire device. Below, it Is explained how this feature can be used to implement 
an effective copy protection scheme. 

4. Close file 
Input: file ID 
Output, none 

5. Get table of contents 
Input: none 

Output : table of contents 

6. Open file 
Input: file ID 
Output: none 

7. Block read 

Input: file ID ' 
Output: data block (e.g. a sector of 512 bytes), sector number for next block read 
Remarks: The application is free to use or discard the sector number for next block 
read at will. Below it is explained how this feature can be used to implement an 
effective copy protection scheme. 

8. Delete file 
Input: file ID 
Output: none 

It -nay be clear that many other useful functions can be defined. For example, error 
signing and reporting has not been taken into account. However, the above 
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Ho«ver, before going mto the details of ^'^^^ ofasing i« ««ot on the 
fn figure 2. Here, the ffl. toj£ » ^£*E3£I5£ « the file, while the 

5ESS^^^" ta * a ^" , • ^,, " ta, * ,l, 

in the file will become clear later. 
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Figure 2. Example structure of a file 
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Digital Rights Management for Solid State Audio players 

One of the short term goals of the Secure Digital Music Initiative (SDMI) is to specify 
a Digiial Rights Management (DRM) system for portable audio players. This DRM ^ 
systeir. not only should enforce observance of copyright rules, but in addition should 
enable new business models as well (e.g. music rental, "try-before-you-buy," and 
controlled copying). By June 30, 1999, the specification should attain such a level as 
to enable development of the next generation of Solid State Audio (SSA) players. 

Two basic tools are available to create a DRM system: encryption and watermarking. 
The fcrmer is used to control access to the audio, while the latter can be used to detect 
illegal copies which have been made using analogue reproduction means. To enable 
new b jsiness models as required by the Music Industry, a method should be provided 
to securely associate usage information with the audio content On each access to the 
conter.t, the usage information should be updated and checked against the rights that 
a were purchased, like a ticket. Of course, it is required to prevent (or detect) so called 

"replay attacks," in which the updated audio content is replaced by the originally 
purchiised pristine (i.e. unUSfed) audio content, which could have been stored in an' 
archive (e.g.-oa a PC hard disk). 

In the following, ft is assumed that the SSA player employs detachable memory 

rnodu.es, which can be accessed by non-compliant devices as well. For consumer 

convenience, it should be possible to plug a loaded memory module in any compliant ■ ■ . 

SSA player and have the audio play, without the need for an on-line transaction, or for 

two payers to be physically connected. After reviewing some simple copy protection 

approaches, a method is proposed which allows prevention of replay attacks under 

these conditions. 

A ver/ simple and straightforward approach to copy protection for SSA is to embed a 
uniqus identification code in each memory module, which can not be modified by a 
user. Alternatively, a "fingerprint" of each memory module may be obtained from the 
location of bad (defect) blocks in the device, and used as the identification code. This 
code <;an be combined with a secret key, which is shared by ail or a group of SSA 
) players, to yield an encryption key which is specific for that memory module. Since 

the secret key is shared, the module specific key can be recovered in each SSA player 
in the group, allowing the audio content to be moved from one player to another. 

However, this approach does not protect against replay attacks, which can be seen as 
follows. Once the audio content is downloaded in the module, it can be read off the 
modi.le using a non-compliant device, and stored in an archive. The audio can not be 
played from the archive because it is stored in encrypted form. However, as soon as 
the content on the memory module has been expired, it can be replaced by a fresh 
copy from the archive. It is clear that this can be repeated indefinitely, and as such this 
method is not suitable to implement new business models such as music rental etc. 

One solution to this problem is to equip the memory module with a smart card IC, 
whic'.i controls access to the memory using some authentication protocol (e.g. based 
on public key cryptography). This would prevent a non-compliant device to copy the 
module content to an archive, and subsequendy to restore it after the original on the 
module has been expired, However, this is a quite costly solution. Moreover, due to 
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K without imposing limitrions on the usage of tt. module. 

Current ** »— * ?I,^^^e«hS^ 
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court (» Implement wear '"' Ul ^^^ 0 ^°° SSn. It is proposed to 
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S^eTfew oftneS^Tf^ or provide a memory of its 

ov^ for that purpose. Figure 2 gives some examples. 

• • a lanrA how the S4T field can be exploited to devise a copy protection 
Nest, it is detaikd how the W l ™«*»* ittwta «nd thus enables new business 
system, which is reastant agamst WjJ^ 1 ^ on ^ memory mo dule in 
nUls to be implemented. The ^et of different keys in the 

a„ < : „crypted form, either Ln purchased with the 

case of block wise encryption. The JJ^JJ"^ ^ ^ module . These need not 

conK at, f b fJ^^ the key(s) used to encrypt 

necsssanly be ^rypted, as wiu oe s k ^ fa derived from 

sectors in which the content ta stored. 
Figure 3 shows this in schematic form. 

^ it i«j assumed that a non-compliant device is 
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audio intent can be made to an intermediate storage device (e.g. a PC hard disk) 
since thtxe are no restrictions whatsoever to reading the memory. However, this copy 
is unliable because it is encrypted with a key that can not be obtained (other than by 
reverse engineering the piayer to determine the shared secret key). On each play back 
of the audio content, the usage information is updated and checked against the rights. 
(Note that the key(s) used to encrypt the audio content are temporarily in the clear for 
play back, but well kept inside the player.) If the content has not been expired, the 
update d information is stored in the memory, and the key(s) used to encrypt the 
conter.t are re-encrypted using the new value of the sectors in which the rights and 
usage information is stored. Now suppose that the audio content has been expired, and 
the bit copy has been placed back in memory. As it turns out, the result is not an exact 
bit copy, because the values in the S4T fields have been changed randomly on each 
write access to the memory. Therefore, the piayer will fail to recover the key(s) used 
to enc rypt the audio content, since this requires the original values of the S4T fields 
(which are on the intermediate storage device, but can not be placed back in the 
^ memory module). Accordingly, the replay attack fails* 

A further potential attack is to change the rights and usage information, which may 
have been stored in the clear, .Again, the value of the S4T field of the sectors in which 
this information is stored will be irrevocably change, thus rendering recovery of the 
key(s) used to encrypt the content impossible. Thus, die attack fails (even if the rights 
and u; age information is stored in the clear). 

To de y this copy protection mechanism, an attacker has to build an interface which 
sits between the player and the memory module. The function of that interface is to 
interojpt the values read from the S4T fields, and to replace them by some standard 
consunt value. (Note that such an attack would work as well against copy protection 
mccht'inisms based on the use of a simple serial number on each memory module.) To 
avoid this attack, a costly mutual authentication of the memory module and player 
using smart card techniques is thought to be inevitable. However, it is surmised that 
this lend of attack is impractical in a portable device. 
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Fig^ie 1. Schematic logical architecture of a memory module containing the 
proposed S4T field. On writing data to a sector in the memory, first the user data is 
stored in the data input register. Then as writing is triggered, the data is transferred to 
the program buffer, and the random number generator generates a new S4T value 
which is to be stored with the data. On reading data from a sector, all data is 
transferred to the data output buffer, including the S4T value. It is up to the 
application to make suitable use of the supplied information. 
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FieuK 2 Some examples of memory modules with the proposed SAT fVmcnonahty. 
WS4T functionality is integrated in the memory chip. (b> An exiatmg memory chip 
. w»j i Conjunction with ^separate controller to implement the S4T func^onality. 
Parf o Se tag area offered by the memory chip is employed to store the S4T daUL(c) 
me same as (b), but now the controller has on-board storage space for the S4T data. 
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Claims: 

1 . A method of copy protection substantially as described herein with reference 
to one or more of the accompanying drawings. 

2. A method of copy protection in which a memory module which provides a tag 
associated with the stored data is used. 

3 . A method of copy protection in which a key which critically depends on the 
exact locations on which it is stored on the memory is used. 

4. A device substantially as described herein with reference to one or more of the 
accompanying drawings. 

5. A device wherein a method as claimed in Claim 1 ,2 or 3 is used for copy 
pxo:ectisg the content stored in the device. 
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